Content Security Policy för Frontend: Avancerat XSS-skydd

I dagens uppkopplade värld är säkerheten för webbapplikationer av yttersta vikt. Cross-Site Scripting (XSS)-attacker förblir ett ihållande hot, som tillåter angripare att injicera skadliga skript på webbplatser som visas av andra användare. Ett av de mest effektiva vapnen i din arsenal mot XSS är Content Security Policy (CSP). Denna guide dyker djupt ner i avancerade CSP-tekniker för att ge ett robust skydd för dina frontend-applikationer, vilket säkerställer en säkrare surfupplevelse för användare över hela världen.

Förståelse för Content Security Policy (CSP)

Content Security Policy (CSP) är en HTTP-svarsheader som låter dig kontrollera vilka resurser en webbsida får ladda. Genom att definiera en CSP talar du om för webbläsaren vilka ursprung (domäner, protokoll och portar) som anses vara säkra källor för innehåll, såsom skript, stilmallar, bilder och typsnitt. När webbläsaren stöter på en resurs som bryter mot CSP:n blockeras resursen, vilket minskar risken för XSS och andra kodinjektionsattacker.

Viktiga CSP-direktiv

CSP fungerar genom en uppsättning direktiv, där vart och ett kontrollerar en annan aspekt av resursladdning. Att förstå dessa direktiv är avgörande för att implementera en effektiv CSP. Här är några av de viktigaste:

• default-src: Detta är fallback-direktivet för alla resurstyper som inte har ett specifikt direktiv tilldelat. Det är generellt god praxis att sätta detta till 'none' för att blockera allt som standard och sedan explicit tillåta specifika källor.
• script-src: Detta direktiv kontrollerar från vilka källor JavaScript kan exekveras. Detta är förmodligen det viktigaste direktivet för att förhindra XSS-attacker.
• style-src: Detta direktiv kontrollerar från vilka källor stilmallar (CSS) kan laddas.
• img-src: Detta direktiv kontrollerar från vilka källor bilder kan laddas.
• font-src: Detta direktiv kontrollerar från vilka källor typsnitt kan laddas.
• connect-src: Detta direktiv kontrollerar de destinationer till vilka webbsidan kan göra nätverksanrop (t.ex. AJAX-anrop, WebSockets).
• media-src: Detta direktiv kontrollerar från vilka källor media (ljud och video) kan laddas.
• object-src: Detta direktiv kontrollerar från vilka källor insticksprogram (t.ex. Flash) kan laddas.
• frame-src / child-src: (child-src föredras) Dessa direktiv kontrollerar från vilka källor ramar (<iframe>) kan laddas. frame-src är föråldrat till förmån för child-src.
• form-action: Detta direktiv kontrollerar de URL:er till vilka formulärinskickningar är tillåtna.

Vanliga CSP-värden

Inom varje direktiv specificerar du tillåtna källor med hjälp av olika värden:

• 'none': Blockerar alla resurser av den typen. Detta är ofta utgångspunkten för en säker CSP.
• 'self': Tillåter resurser från samma ursprung (schema, domän och port) som sidan.
• 'unsafe-inline': Tillåter inline JavaScript (t.ex. händelsehanterare som onclick) och inline CSS. Detta avråds generellt från på grund av säkerhetsriskerna.
• 'unsafe-eval': Tillåter användning av osäkra JavaScript-funktioner som eval(), new Function() och setTimeout() med ett strängargument. Detta avråds starkt från.
• data:: Tillåter laddning av resurser från data-URI:er (t.ex. bilder inbäddade direkt i HTML).
• *: Tillåter alla källor. Använd detta sparsamt, om alls, eftersom det allvarligt begränsar effektiviteten av CSP.
• URL:er (t.ex. https://example.com, https://*.example.com): Tillåter resurser från specificerade URL:er. Jokertecken (*) kan användas för subdomäner.
• nonce-värde: Tillåter inline-skript eller -stilar med ett specifikt nonce-attribut. Detta är den rekommenderade metoden för att tillåta inline JavaScript när det är absolut nödvändigt. (Se avsnittet 'Nonces och Hashar').
• sha256-hashvärde, sha384-hashvärde, sha512-hashvärde: Tillåter inline-skript eller -stilar vars innehåll matchar en specifik kryptografisk hash. (Se avsnittet 'Nonces och Hashar').

Implementera en robust CSP

Att implementera en stark CSP kräver noggrann planering och utförande. Här är en steg-för-steg-guide:

1. Bedömning och planering

Innan du börjar måste du förstå hur din applikation fungerar. Identifiera alla resurser som din applikation laddar, inklusive skript, stilmallar, bilder, typsnitt och eventuella externa tjänster den interagerar med. Tänk på din applikations arkitektur och hur data flödar genom den. Att noggrant dokumentera din applikations resursladdningsbeteende är avgörande.

Exempel: En global e-handelsplattform kan ladda skript från sin egen domän (t.ex. www.example.com), innehållsleveransnätverk (CDN) som Cloudflare eller Akamai, och potentiellt tredjepartstjänster för analys eller betalningshantering. Planen måste ta hänsyn till alla dessa källor, även de som kommer från olika länder eller regioner.

2. Börja med en restriktiv policy (Standard 'none')

Bästa praxis är att börja med en mycket restriktiv policy och gradvis lätta på den vid behov. Börja med default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self';. Denna policy blockerar allt som standard och tillåter endast att skript, stilar och bilder laddas från samma ursprung. Detta ger omedelbart en stark grundläggande skyddsnivå.

Exempel:

            Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self';
            

              
                Copy
              
            
          

3. Identifiera externa resurser

Identifiera sedan alla externa resurser som din applikation använder. Detta inkluderar CDN:er, tredjeparts-API:er och alla andra domäner från vilka din applikation laddar tillgångar. Granska din HTML-källkod och nätverkstrafik för att avslöja alla externa beroenden.

Exempel: Din applikation kan använda Google Fonts, ett JavaScript-bibliotek som hostas på ett CDN, och ett API från en betalningsgateway. Dokumentera dessa externa källor tillsammans med de specifika protokoll och portar som används.

4. Lätta på policyn stegvis

För varje extern resurs, lägg till lämpligt direktiv och källa i din CSP. Om du till exempel använder ett CDN, tillåt det CDN:et i dina script-src och/eller style-src direktiv. Var så specifik som möjligt. Undvik att använda jokertecken om det inte är nödvändigt. Testa din applikation noggrant efter varje ändring för att säkerställa att den fortsätter att fungera korrekt och att CSP:n effektivt blockerar skadliga resurser.

Exempel: Om din applikation använder Google Fonts kan du lägga till font-src https://fonts.gstatic.com; och style-src https://fonts.googleapis.com; i din CSP. Om du använder ett CDN, som cdn.example.com, lägg då till script-src cdn.example.com; style-src cdn.example.com;.

5. Driftsättning och testning

När du har etablerat din CSP, driftsätt den i din produktionsmiljö. Testa den noggrant i olika webbläsare och enheter. Använd webbläsarens utvecklarverktyg och säkerhetstestverktyg för att identifiera eventuella överträdelser. Granska och uppdatera regelbundet din CSP i takt med att din applikation utvecklas.

6. Övervakning av överträdelser

Implementera en mekanism för att övervaka CSP-överträdelser. När en webbläsare blockerar en resurs på grund av en CSP-överträdelse skickar den en rapport som du kan analysera. Du kan konfigurera denna rapportering med hjälp av report-uri- eller report-to-direktiven.

report-uri: Detta direktiv specificerar en URL till vilken webbläsaren ska skicka rapporter när en CSP-överträdelse inträffar. Detta direktiv är nu föråldrat till förmån för report-to.

report-to: Detta direktiv specificerar en lista över rapporteringsslutpunkter till vilka webbläsaren ska skicka rapporter. Detta ger mer flexibilitet i hanteringen av rapporter och är den moderna rekommenderade metoden.

Exempel (report-to):

            Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; report-to csp-reports;

<?php
  $nonce = bin2hex(random_bytes(16)); // Generera ett slumpmässigt nonce
  header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{$nonce}'; style-src 'self' 'nonce-{$nonce}';");
?>
<script nonce="">
  // Din inline JavaScript-kod
</script>

            

              
                Copy
              
            
          

2. Strict-Dynamic

Källvärdet 'strict-dynamic' är en mer avancerad metod. Det tillåter skript att ladda andra skript dynamiskt, så länge det ursprungliga skriptet som laddar de andra skripten är tillåtet. Detta kan vara användbart för ramverk och bibliotek som laddar skript dynamiskt. Använd detta försiktigt och endast om du helt förstår dess konsekvenser.

Hur det fungerar: När 'strict-dynamic' används med script-src, litar webbläsaren på skript som laddas via ett betrott skript. Alla skript som läggs till dynamiskt av ett betrott skript kommer också att tillåtas. Det initiala betrodda skriptet måste laddas genom en annan mekanism, såsom ett nonce eller en hash.

Exempel:

            Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{{ nonce }}' 'strict-dynamic';
            

              
                Copy
              
            
          

I detta exempel är det endast skriptet med nonce som initialt är betrott. Men alla skript som detta skript laddar dynamiskt kommer också att vara betrodda.

3. Trusted Types

Trusted Types är en webbläsarfunktion som låter dig förhindra DOM-baserade XSS-attacker genom att tvinga fram ett strikt API för att skapa och hantera potentiellt farlig data. Det ersätter möjligheten att direkt skapa HTML från strängar. Det kräver att du omvandlar osäkra strängar till 'betrodda' objekt med hjälp av 'sanitizers'. Detta skyddar mot DOM-baserade XSS-sårbarheter i ramverk och bibliotek.

Hur Trusted Types fungerar:

1. Definiera en policy.
2. Registrera policyer för specifika åtgärder (t.ex. `innerHTML`).
3. Använd en sanitizer för att sanera data innan den tilldelas en DOM-egenskap.

Exempel (Konceptuellt):

            // Skapa en TrustedType-policy
const policy = trustedTypes.createPolicy('myPolicy', {
    createHTML: (string) => { //Sanitizer. Returnera ett trustedHTML-objekt.
        // Sanera HTML-strängen innan du returnerar en betrodd typ
        return string;
    }
});

// Använd policyn för att ställa in innerHTML
document.body.innerHTML = policy.createHTML("<img src='x' onerror='alert(1)'>");

            

              
                Copy
              
            
          

För närvarande är webbläsarstödet för Trusted Types relativt begränsat, men det är en effektiv försvarsåtgärd mot DOM-baserad XSS när den används korrekt. Att implementera Trusted Types kan avsevärt minska attackytan.

4. Rapportera överträdelser (report-to / report-uri)

Att sätta upp korrekt rapportering av överträdelser är avgörande för att övervaka och underhålla din CSP. Använd report-to (föredraget) eller report-uri för att skicka överträdelserapporter till en slutpunkt som du kontrollerar. Dessa rapporter ger värdefulla insikter om potentiella XSS-attacker och felkonfigurationer.

Hur man använder rapportering:

1. Ange report-to- eller report-uri-direktivet.
   • report-to: är den föredragna metoden. Ange slutpunkten dit överträdelserapporter ska skickas.
   • report-uri: är en föråldrad metod, den specificerar URL:en till rapporteringsslutpunkten.
2. Ange HTTP-headern Content-Security-Policy-Report-Only (eller motsvarande metatagg): Använd denna header initialt för att övervaka överträdelser utan att blockera resurser. Detta låter dig identifiera och åtgärda problem innan du tvingar igenom CSP:n i din produktionsmiljö.
3. Skapa en rapporteringsslutpunkt. Du kan bygga en enkel serverapplikation (t.ex. med Node.js, Python eller PHP) för att ta emot och bearbeta rapporterna. Eller använd en tredjepartstjänst för övervakning.
4. Analysera rapporterna. Granska detaljerna i överträdelsen, inklusive den blockerade URI:n, det överträdda direktivet och källan till skriptet. Denna information kan hjälpa dig att identifiera och åtgärda XSS-sårbarheter och felkonfigurationer.

5. CSP i metataggar (endast rapportering och tvingande)

CSP kan levereras på två sätt: som en HTTP-header eller som en <meta>-tagg i din HTML.

• HTTP-header: Den rekommenderade metoden, att leverera CSP som en HTTP-header, är generellt sett säkrare eftersom den tillämpas innan sidans innehåll tolkas. Detta förhindrar potentiella omvägar som är möjliga med <meta>-taggar.
• <meta>-tagg: Du kan också inkludera CSP med en <meta>-tagg i din HTML:s <head>-sektion. Attributet http-equiv specificerar typen av policy. Till exempel: <meta http-equiv="Content-Security-Policy" content="...">.

<meta>-taggen erbjuder attributet `Content-Security-Policy-Report-Only` för att distribuera CSP i endast-rapporteringsläge. Detta låter dig övervaka överträdelser utan att blockera någonting.

Endast-rapporteringsläge (rekommenderas för initial driftsättning):

            <meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'self'; script-src 'self' https://example.com; report-to csp-reports;">
            

              
                Copy
              
            
          

Detta läge låter dig samla in överträdelserapporter utan att påverka din webbplats funktionalitet. Du kan använda det för att testa din CSP och identifiera eventuella problem innan du tvingar igenom den i produktion. Granska överträdelserapporter, justera din CSP vid behov och byt sedan till `Content-Security-Policy`-headern för att tvinga igenom den.

6. CSP med brandväggar för webbapplikationer (WAFs)

En brandvägg för webbapplikationer (WAF) ger ett extra säkerhetslager för dina webbapplikationer. WAFs kan användas för att upptäcka och blockera skadlig trafik, inklusive XSS-attacker. Du kan konfigurera din WAF att arbeta tillsammans med din CSP för att förbättra din säkerhetsposition.

Hur WAFs och CSP kan samarbeta:

1. WAF som första försvarslinje: En WAF kan filtrera skadliga förfrågningar innan de når din applikation. Den kan identifiera och blockera kända XSS-attackmönster.
2. CSP som andra försvarslinje: CSP ger ett extra skyddslager genom att begränsa vilka resurser en sida kan ladda, även om skadligt innehåll lyckas ta sig förbi WAF:en.
3. Integration med CSP-rapporter: Vissa WAFs kan integreras med CSP-överträdelserapporter. De kan varna dig för potentiella attacker och ge detaljerad information om attackens natur.

Bästa praxis och handlingsbara insikter

• Börja restriktivt: Börja med en mycket restriktiv CSP (t.ex. default-src 'none';). Detta minimerar attackytan.
• Testa noggrant: Testa din CSP rigoröst i alla större webbläsare och på olika enheter innan du driftsätter i produktion. Använd både manuell testning och automatiserade testverktyg.
• Övervaka överträdelser: Övervaka och analysera regelbundet CSP-överträdelserapporter för att identifiera och åtgärda säkerhetsproblem. Ställ in automatiska varningar för att bli meddelad om eventuella attacker.
• Håll den uppdaterad: I takt med att din applikation utvecklas, uppdatera din CSP för att återspegla ändringar i dina resursladdningsmönster. Håll dig uppdaterad med bästa praxis för säkerhet.
• Undvik 'unsafe-inline' och 'unsafe-eval': Dessa värden försvagar din CSP avsevärt och bör undvikas. Använd alltid nonces eller hashar för inline-skript/stilar.
• Använd endast-rapporteringsläge initialt: När du driftsätter en ny CSP eller gör betydande ändringar, använd endast-rapporteringsläge för att testa policyn och identifiera potentiella problem innan du tvingar igenom den.
• Överväg tredjepartstjänster: Använd tjänster (som Sentry, Report URI eller Cloudflare) för att hjälpa till med CSP-rapportering och analys. Detta kan förenkla processen och ge värdefulla insikter.
• Utbilda ditt team: Se till att ditt utvecklingsteam förstår vikten av CSP och följer säkra kodningspraxis för att minimera risken för XSS-sårbarheter. Utbilda dina utvecklare i bästa praxis för säker kodning och tekniker för att förebygga XSS.
• Implementera säkerhetsrevisioner: Utför regelbundet säkerhetsrevisioner för att identifiera sårbarheter och bedöma effektiviteten av din CSP.
• Använd automatisering: Automatisera processen för att generera nonces och hashar. Integrera CSP-testning i din CI/CD-pipeline.

Globala överväganden

När du implementerar CSP för en global publik, överväg följande:

• Prestanda: Minimera påverkan av CSP på webbplatsens prestanda. Använd effektiva tekniker för resursladdning och optimera din CSP för att undvika onödiga restriktioner. Välj geografiskt distribuerade CDN:er för tillgångar.
• Lokalisering: Se till att din CSP inte stör lokaliserat innehåll eller resurser. Om du till exempel använder ett CDN för översatt innehåll, se till att du inkluderar det CDN:et i din CSP.
• Tillgänglighet: Testa din CSP för att säkerställa att den inte negativt påverkar tillgängligheten för användare med funktionsnedsättningar.
• Regionala regleringar: Var medveten om dataskyddsregleringar i olika regioner. Till exempel kan den allmänna dataskyddsförordningen (GDPR) i Europeiska unionen och California Consumer Privacy Act (CCPA) i USA påverka hur du samlar in och behandlar användardata, vilket kan påverka din CSP-konfiguration.
• Mobila användare: Testa din CSP på mobila enheter och webbläsare för att säkerställa att den ger tillräckligt skydd och inte hindrar den mobila användarupplevelsen. Mobila enheter och webbläsare hanterar ofta CSP något annorlunda, så noggrann testning är avgörande.

Slutsats

Att implementera en avancerad Content Security Policy är ett avgörande steg för att skydda dina webbapplikationer från XSS-attacker. Genom att börja med en restriktiv policy, noggrant konfigurera direktiv och använda tekniker som nonces, hashar och rapportering, kan du avsevärt minska din attackyta och förbättra säkerheten för din globala webbnärvaro. Kom ihåg att testa din CSP noggrant, övervaka överträdelser och kontinuerligt uppdatera din policy i takt med att din applikation utvecklas. Genom att anamma dessa bästa praxis kan du skydda dina användare och upprätthålla förtroendet för ditt varumärke, oavsett deras plats eller bakgrund.